Not sure what issues the PR is trying to resolve but the approach is not right for any problem.

1. We've never asked Egress IP to be pingable.
2. We've never asked Egress IP to be configured on node interface before it can be used for Egress IP. They can be done by the opposite order.
3. Testing an IP's reachability in a control-plane component is rarely a good idea.

Not sure what issues the PR is trying to resolve but the approach is not right for any problem.

1. We've never asked Egress IP to be pingable.
2. We've never asked Egress IP to be configured on node interface before it can be used for Egress IP. They can be done by the opposite order.
3. Testing an IP's reachability in a control-plane component is rarely a good idea.

@tnqn trying to resolve issue linked with PR:
For Egress with ExternalIPPool, when EgressIP isn't assigned to any Node, Egress is not applied to Pod. Pod to external traffic goes via host NodeIP SNAT (Normal encap mode). But this is not the case for static Egress, when EgressIP isn't available on any Node, still Egress is applicable to Pod and Pod to external traffic is unsuccessful behaviour should be consistent for Both the cases.

@tnqn trying to resolve issue linked with PR:
For Egress with ExternalIPPool, when EgressIP isn't assigned to any Node, Egress is not applied to Pod. Pod to external traffic goes via host NodeIP SNAT (Normal encap mode). But this is not the case for static Egress, when EgressIP isn't available on any Node, still Egress is applicable to Pod and Pod to external traffic is unsuccessful behaviour should be consistent for Both the cases.

But I don't see how the PR unifies the behavior when EgressIP isn't available and it breaks the usage of static Egress in an unreliable way.